<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Password issues',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/05/17.jpg" alt="A sidewalk lines with small trees" class="framed-centred-image" width="649" height="480"/>
<section id="utilities">
	<h2>Envelopes</h2>
	<p>
		The utility company keeps sending me these envelopes with which to mail bill payments back to them.
		It&apos;s a waste of good paper, seeing as I always pay my bill in person.
		During that period in which I had no bill to pay because they&apos;d refunded my initial deposit as a bill credit, they still kept sending me envelopes, which was particularly stupid.
		I started saving up the envelopes to bring back in hopes they could reuse them, sending them to other customers.
	</p>
	<p>
		I tried to return them today, but no can do.
		They can&apos;t take them back because of health concerns.
		I may have contaminated them in some way; they just have no way to know.
		They recommended I register for electronic statements, as then they wouldn&apos;t need to send bills to me at all via post, but you can&apos;t register without a telephone number.
		I think I&apos;d tried in the past, but hit that wall.
		It turns out that they have a stupid system that uses the telephone number to match the online account to the service account.
		No telephone number on file means no possibility of registering an online account.
		They offered to put a temporary fake number on the account so I could register when I got home, then they&apos;d remove the number later, but I wasn&apos;t interested.
		I don&apos;t want a telephone number on the account.
		I don&apos;t want someone mistakenly thinking they can reach me via telephone in the mean time, so i was going to leave and just let them keep wasting their paper.
		It&apos;s their broken system, so it&apos;s their problem.
	</p>
	<p>
		However, one of the representatives offered to set the account up for me in-office.
		They&apos;d put the company&apos;s own telephone number onto my account as my own, set up the account, then remove the number.
		That sounded good.
		As we went to set it up though, I needed a password right away.
		I had no access to my KeePassX database, seeing as we weren&apos;t working on my computer.
		I was going to cancel, but they talked me into using a temporary password.
		The account&apos;s set up now, but when I tried to change the password, I ran into difficulties.
		The website demands non-alphanumeric characters be used, but doesn&apos;t accept all characters.
		It doesn&apos;t even accept al characters from the basic Latin block.
		Even worse, it won&apos;t tell me what characters it has a problem with, it just tells me it doesn&apos;t like my passwords.
		Newer versions of KeePassX are stupid and won&apos;t allow the specification of allowed character sets, either.
		It&apos;s either all non-alphanumeric character that it uses are fair game or none of them are used at all.
		I don&apos;t have time for this today, so for now, I&apos;m just stuck with pretty much the easiest to guess password I could come up with in-office that contained a non-alphanumeric character.
	</p>
</section>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			Initially, I was looking at this all wrong.
			I was trying to figure out how the stop and wait protocol could <strong>*cause*</strong> a process to crash, which didn&apos;t really add up.
			There&apos;s nothing particularly crash-inducing about that method of transmission.
			I get it now though.
			This family of transmissions doesn&apos;t hold up well if the process on one side of the transmission crashes partway through, possibly for unrelated reasons.
			The stop-and-wait strategy is just too simple to be practical on its own.
		</p>
		<p>
			Assuming we use the simple acknowledge-upon-receipt strategy for the receiver and the retransmit-upon-timeout strategy for the sender, if the receiving process crashes, the sender will continuously retransmit.
			The receiver will ignore the packets, as the process that&apos;s supposed to handle them won&apos;t be running, so packets received on that port will be treated as garbage data.
			With no acknowledgements received, the sender won&apos;t know that there&apos;s a reason not to keep transmitting and trying.
			If the sending process instead crashes, it obviously stops transmitting partway through, and the receiver is left waiting continuously for data that will never arrive.
		</p>
		<p>
			With the two-acknowledgement-type system, we see a similar issue, though when the sending process crashes, the receiver could be in its usual wait-for-the-sender-to-resend mode or in its resend-the-acknowledgement-repeatedly mode.
			If the former, we have the exact same issue as before when the sender crashed, while in the latter, we have a similar problem to when the receiver crashed in previous setup, but in reverse, as it&apos;s the receiver that won&apos;t stop sending packets.
		</p>
		<p>
			Basically, what we need in the stop-and-wait transmission strategy is some sort of timeout not only for individual packets, but also for the process as a whole.
			If one end of the communicating duo hasn&apos;t heard from the other in a minute or two (which is <strong>*ages*</strong> at the speed of a typical network), the transmission needs to be assumed to have failed, at which point the sender can try again.
			In the case of the file-retrieval situation presented by this discussion assignment, the sender is simply sending a file requested by the receiver, so the sender shouldn&apos;t do anything to retransmit right away.
			Instead, it should fall on the receiver to re-request the file to try to start the process again.
			Of course, if the receiving process is the one that crashed, it can&apos;t do that until it comes back online, and if the sending process has crashed, it might not be back online yet to service the request.
			Neither of these issues is tied specifically to the stop-and-wait transmission strategy though.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Dordal, P. (2014). 6 Abstract Sliding Windows - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="http://intronetworks.cs.luc.edu/current/html/slidingwindows.html"><code>http://intronetworks.cs.luc.edu/current/html/slidingwindows.html</code></a>
			</p>
		</div>
	</blockquote>
</section>
END
);
